Use RFC 3339/9557 rules for :datetime, :date & :time operand values - #1105
Use RFC 3339/9557 rules for :datetime, :date & :time operand values#1105eemeli wants to merge 1 commit into
Conversation
|
Replying here to @rxaviers from #1104 (comment):
In both cases I'd expect a Bad Operand. For the former, the proposal specifically includes this: message-format-wg/spec/functions/datetime.md Lines 205 to 206 in f6be593 For the latter, I'd expect for the implementation to not accept the value as a valid "implementation-defined date/time type" for the function. |
| If the _resolved value_ of the _operand_ does not include a time, | ||
| `00:00:00` is used as the time. |
There was a problem hiding this comment.
Note that time 00:00 is not guaranteed to exist for every date in any particular time zone, although that is also true for e.g. 02:xx.
| If the _resolved value_ of the _operand_ does not include a time, | ||
| `00:00:00` is used as the time. |
There was a problem hiding this comment.
Here in :date, nonexistence probably matters more.
| If the _resolved value_ of the _operand_ does not include a time, | |
| `00:00:00` is used as the time. | |
| If the _resolved value_ of the _operand_ does not include a time, | |
| `12:00:00` is used as the time. |
| or a string matching the `time` rule of | ||
| [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339#section-5.6). |
There was a problem hiding this comment.
I do not see a time rule in RFC 3339 section 5.6. There is one in RFC 3339 Appendix A, although it allows values like "1023:42"/"-23"/"-23:42"/"--42"/"10-05" so I don't think we should use it.
| [RFC 9557](https://www.rfc-editor.org/rfc/rfc9557#name-abnf), | ||
| or a string matching the `full-date` rule of | ||
| [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339#section-5.6). | ||
| All other _operand_ values produce a _Bad Operand_ error. |
There was a problem hiding this comment.
@eemeli said: For (time), the proposal specifically includes this:
If the resolved value of the operand does not include a time,
a Bad Operand error is produced.
@eemeli, for consistency, shall we include the analogous here?
| All other _operand_ values produce a _Bad Operand_ error. | |
| All other _operand_ values produce a _Bad Operand_ error. | |
| If the _resolved value_ of the _operand_ does not include a date, | |
| a _Bad Operand_ error is produced. |
... to guarantee this edge case also produces Bad Operand
3 participants
Closes #680
Since the current regular expression definition of "Date and Time Operands" was added to the spec in #687, RFC 9557 has been published, the datetime functions got refactored in #1083, and we're now this close to having Temporal advance to Stage 4 at TC39.
With all fo the above in mind, we ought to revisit the rules for the
:datetime,:date, and:timeoperands, and define their string values separately, relying on RFC 9557 or RFC 3339 rules, as proposed here.I'm not 100% sure about allowing the
timerule for:timeoperands, as I think we'd be best served by something likewith the fractional and integer seconds being optional, but I've not found a good reference for such a rule. I'm not completely convinced that we ought to accept a time with an offset but no date as a literal value, as
timeallows for.